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MANAGEMENT  SUMMARY 


Business  Process  Improvement 
as  a 

Component  of  Defense  Strategy 


This  paper  attempts  to  establish  a  framework  for  Corporate 
Information  Management  as  a  methodology  for  information 
management  in  the  DoD  and  to  evaluate  those  business  process 
improvement  concepts,  such  as  business  process  redesign  and 
functional  economic  analysis,  as  components  of  Defense  strategy. 

••The  primary  objective  of  CIM  is  business  process  improvement. 

The  role  of  information  technology  is  supportive  ...":  statement 
by  Duane  Andrews,  ASD  (C3I)  before  the  House  Appropriations 
Committee,  April  24,  1991. 

••The  essence  of  CIM  is  the  idea  of  being  ready  to  fight  on 
arrival.  CIM  is  not  about  payroll,  logistics,  inventory 
management  —  it  is  about  fighting.  Our  information  systems  are 
the  backbone  of  our  fighting  capability”:  statement  by  Paul 
Strassmann  at  the  IRM  College,  February  25,  1992. 

At  first  reading,  these  two  statements  may  appear  to  be,  if  not 
contradictory,  not  fully  consistent  with  on  another.  What  does 
redesigning  processes  for  payroll  or  personnel  systems  have  to  do 
with  commahd  and  control  of  the  fighting  force?  This  paper  will 
explore  those  Corporate  Information  Management  concepts  for  the 
improvement  of  business  processes  and  their  projection  into  the 
strategic  defense  arena.  It  will  attempt  to  trace  a  line  through 
the  CIM  doctrine  to  connect  DoD's  business  management  role  with 
its  war  management  and  war  fighting  role  (command  and  control)  . 

There  are  two  common  command  management  threads  which  cross  the 
spectrum  of  DoD  information  systems:  (1)  All  systems  are 
becoming  information  systems.  (2)  An  information  war  (which 
some  have  said  Dessert  Storm  was  the  precursor)  requires  the 
fullest  possible  interoperability  -  and  interoperability  will 
come  only  through  systems  integration. 

There  are  also  two  common  information  management  threads  that 
cross  the  continuum  of  information  systems  applications  from 
tooth  to  tail:  (1)  Managing  data  and  the  process  of  its 
conversion  to  information  is  the  basis  for  managing  information 
systems.  (2)  Managing  the  software  development  and  maintenance 
process  will  determine  who  wins  the  interoperability  and 
integration  battle. 


The  DoD  has  embarked  on  a  significant  initiative  to  improve  the 
functional  processes  that  undergird  both  administrative  and 
command  (operational)  systems.  Corporate  Information  Management 
(CIM)  is  based  on  the  concept  that  "DoD's  information  management 
decisions  must  be  made  on  a  business  case  basis"  (6) .  That 
initiative  has  introduced  Business  Process  Improvement  as  the 
fundamental  management  strategy  for  absorbing  budget  cuts  under 
the  Defense  Management  Review  (DMR) .  One  of  the  principal 
initiatives  of  a  Business  Process  Improvement  Program  (BPIP)  in 
any  functional  component  is  Business  Process  Redesign  (BPR) . 
"Capturing  the  business  rules"  is  the  end  objective  of  Business 
Process  Redesign.  Information  Engineering  (IE)  originated 
structured  techniques  for  process  and  data  modeling  which  were 
integrated  with  the  information  systems  design  and  development 
process.  The  CIM  emphasis  on  BPR  has  spotlighted  process  and 
data  modeling  as  the  proven  method  of  capturing  business  rules 
and  for  documenting  a  business  case.  Methods  and  tools  (IDEE) 
have  been  formally  adopted  which  the  functional  user  may  employ 
for  analyzing  business  practice  and  for  BPR. 

This  is  the  crux  of  CIM.  By  getting  control  of  the  true 
functionality,  through  defining  the  business  rules,  we  can 
finally  get  control  of  the  run-away  information  systems  that  have 
grown  up  helter  skelter  to  support  the  "perceived  functionality". 
The  logical  extension  of  this  concept  beyond  the  business 
environment  is  to  capture  the  "decision  rules"  as  they  relate  to 
command  and  control  or  intelligence  processes.  This  may  some  day 
result  in  a  methodology  for  "decision  process  improvement." 
Cross-functional  interoperability  will  then  be  possible  through  a 
common  management  paradigm  for  information  integration. 

The  CIM  management  paradigm  in  context  with  an  Integration 
Architecture,  holds  the  greatest  promise  of  achieving  cross¬ 
functional  integration. 
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BUSINESS  PROCESS  IMPROVEMENT 


AS  A 

COMPONENT  OF  DEFENSE  STRATEGY 


INTRODUCTION: 

Like  the  rest  of  American  society,  the  Department  of  Defense  is 
becoming  heavily  information  driven  by  way  of  large  data 
repositories  and  communications  freeways  which  support  not  only 
its  administrative  operations  but  its  military  operations  as 
well.  As  a  result  of  the  Corporate  Information  Management  (CIM) 
strategy,  the  DoD  has  embarked  on  a  significant  initiative  to 
improve  the  functional  processes  that  undergird  both 
administrative  and  command  (operational)  systems.  Although  the 
primary  thrust  of  CIM  is  "getting  the  business  rules  right" 
rather  than  automation,  this  is  also  the  CIM  imperative  for 
building  (or  rebuilding)  DoD  information  systems.  This  paper 
will  examine  the  impact  of  CIM  as  a  management  strategy  and  its 
application  over  the  entire  spectrum  of  DoD  information  systems  - 
from  "Tooth"  to  "Tail”. 

Corporate  Information  Management  (CIM)  is  based  on  the  concept 
that  "DoD's  information  manjagement  decisions  must  be  made  on  a 
business  case  basis".  It  has  also  been  defined  as  "being  ready 
to  fight  on  arrival".  These  seemingly  contradictory  concepts  are 
emerging  as  a  single  unified  doctrine  for  information  resources 
management  in  the  Department  of  Defense. 

"The  essence  of  CIM  is  the  idea  of  being  ready  to  fight  on 
arrival.  CIM  is  not  about  payroll,  logistics,  inventory 
management  ...  it  is  about  fighting.  Our  information 
systems  are  the  backbone  of  our  fighting  capability" 

Address  by  Mr. Paul  Strassmann 
at  IRM  College,  25  February  1992 


WHAT  IS  THE  CONNECTION  BETWEEN  BUSINESS  PROCESS  IMPROVEMENT,  CIM, 
AND  INFORMATION  RESOURCES  MANAGEMENT  (IRM)? 

The  original  design  concept  for  CIM  as  defined  for  the  Defense 
Management  Review  by  the  Executive  Level  Group  (ELG)  is  shown  in 
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Figure  1.  As  a  member  of  the  ELG,  Mr.  Paul  Strassmann  (now  the 
Director  of  Defense  Information)  was  one  of  the  architects  of 
this  model .  It  is  evident  that  one  of  the  central  concepts  of 
the  ELG  model  is  the  use  of  process  and  data  models  to  evaluate 
business  practices.  These  models  actually  take  two  forms: 

(1)  The  first  modeling  activity  is  conducted  by  the 
functional  community  and  is  focused  on  determining  best 
business  practices  for  improving  the  functional  processes  or 
activities,  within  constraints  of  economics  and  risk.  It  is 
done  to  capture  the  business  rules  from  the  existing 
functionality  and  perform  business  case  analysis  on  the 
baseline  process  and  any  proposed  improvements  in  business 
practices.  Models  are  developed  using  a  standard 
methodology:  the  Integrated  Definition  (IDEF)  language 
originally  developed  by  the  Air  Force.  Activity  Based 
Costing  (ABC)  methods  have  become  prominent  in  both  the 
private  and  public  sectors  for  determining  cost  drivers  and 
tracking  activity  costs.  This  is  where  business  process 
redesign  occurs.  It  is  based  on  the  premise  that,  after 
establishing  and  costing  the  existing  baseline  activities, 
an  alternatives  analysis  is  used  to  eliminate  non-value 
added  activities  and  project  costs  of  process  improvement 
options.  A  business  case  decision  considers  many  factors 
including:  investment  risk  analysis,  discounted  cash  flow 
analysis,  affordability  analysis  and  make  vs.  buy  analysis. 
However  the  investment  decision  is  a  return  on  investment 
decision  NOT  a  technology  decision. 

(2)  The  second  modeling  activity  is  conducted  by  the  IRM 
community  in  concert  with  the  end  user.  It  is  done  through 
information  engineering  (IE)  methods  to  develop  the  logical 
and  physical  models  of  an  automated  information  system. 

(This  assumes  that  automation  is  the  business  practice  that 
demonstrates  highest  return  on  investment  in  the  business 
case  analysis.)  The  principal  outputs  of  IE  are  also 
process  and  data  models.  Integrated  Computer  Aided  Software 
Engineering  (ICASE)  tools  are  used  to  guide  the  model 
development  and  store  the  final  models  for  the  life  of  the 
information  system. 

The  ELG  model  in  Figure  1  has  profound  implications  for 
information  resources  management  in  the  DoD: 

.  It  imposes  a  systematic  approach  to  information  system 
design  and  development  which  is  based  upon  functional 
economic  analysis  of  the  business  requirement. 

.  It  links  business  analysis  to  systems  analysis  through 
process  and  data  modeling  methodology. 
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CORPORATE  INFORMATION  MANAGEMENT  MODEL 

Figure  1 


INFORMATION  SYSTEMS 


It  establishes  CIM  as  the  implementing  strategy  for 
information  resources  management  in  the  DoD. 

It  establishes  information  engineering  with  ICASE  as  the 
design  and  development  strategy  for  business  systems. 


WHAT  IS  BUSINESS  PROCESS  REDESIGN? 


"Every  Live-Birth 

always  has  an  Episode-Of-Healthcare 
always  has  an  Episode-Of-Hospital-Care 

always  INITIATES  zero,  one  or  many  Hospital-Admission(s) 
always  RESULTS-IN  zero,  one  or  many  Newborn- Infants" 

The  foregoing  is  a  statement  taken  from  the  Army  Surgeon 
General's  AMEDD  Architecture  (1).  It  is  an  excerpt  from  over 
twenty  pages  of  business  rules  that  were  captured  through  IDEE 
activity  analysis  and  data  (business  rule)  modeling. 

More  than  any  other  description,  the  above  example  best 
characterizes  the  end  objective  of  Business  Process  Redesign 
-  to  document  agreed  upon  business  rules  that  reflect  the 
functionality  of  the  business  system. 

Process  and  data  modeling  techniques  and  the  CIM  policy  and 
resulting  procedures  for  business  case  development  are  important 
in  a  procedural  sense.  However,  the  definition,  documentation 
and  acceptance  by  the  functional  community  of  the  business  rules 
that  underlie  their  business  processes  is  the  ultimate  end-game. 

The  CIM  Process  Improvement  Methodology  for  Functional  Users  ( 5 ) 
defines  Business  Process  Redesign  (BPR)  as; 

"The  action  of  analyzing  AS-IS  activity  and  rule  models  with 
the  intent  to  construct  a  TO-BE  activity  and  rule  model  that 
will  yield  potential  improvements  in  perfoxnnance  of  the 
business  process." 

This  analysis  is  accomplished  in  the  context  of  a  larger  Business 
Process  Improvement  Program  (BPIP)  which  is  defined  as: 

"The  application  of  a  Business  Process  Redesign  Methodology 
to  one  or  more  related  business  processes  enabling  an 
enterprise  to  improve  the  value  of  its  products  and  services 
while  reducing  resource  requirements.  The  results  of  a 
successful  BPIP  are  productivity  and  quality  improvements. 

A  business  case  or  action  plan  is  a  required  deliverable  for 
all  BPIP  actions." 
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These  definitions  provide  the  foundation  concepts  for  business 
process  improvement  and  its  natural  extension  -  business  process 
redesign  (BPR) .  The  concept  of  capturing  business  rules  using 
process  and  data  modeling  techniques  is  not  new.  However,  in  the 
past,  it  was  the  responsibility  of  the  IRM  community  to  build 
these  models  as  part  of  the  design  of  an  information  system.  With 
the  advent  of  Information  Engineering  (IE) ,  formalized  techniques 
for  process  and  data  modeling  became  a  part  of  that  design 
process.  Today,  these  models  are  integral  to  the  information 
systems  design  and  development  process  through  the  use  of 
Computer  Assisted  Software  Engineering  (CASE)  tools.  The 
emphasis  of  CIM  on  Business  Process  Redesign  has  spotlighted 
process  (activity)  and  data  (business  rule)  modeling.  Methods 
and  tools  (IDEE)  have  been  formally  adopted  with  which  the 
functional  business  analyst  can  capture  the  business  rules  which 
will  govern  improvements  in  cost,  quality  or  level  of  service. 
This  analysis  should  consider  all  available  opportunities  for 
best  business  practice  without  being  driven  by  information 
technology  considerations.  Business  analysis  techniques  are  part 
of  an  overall  mosaic  of  methods  and  tools  leading  to  the 
articulation  and  approval  of  a  business  case  and  subsequent 
initiation  of  a  Business  Process  Improvement  Program  (BPIP) . 
Figure  2  provides  an  overview  of  the  BPIP. 

A  comprehensive  discussion  of  Figure  2  is  beyond  the  scope  of 
this  paper.  However,  the  critical  success  factors  for  a  BPIP  are 
listed  in  Appendix  A.  The  ultimate  objective  of  a  BPIP  is  the 
discovery,  documentation  and  agreement  by  the  functional 
community  on  some  fundamental  statements  for  the  business  rules. 
Inculcating  the  infrastructure  for  BPIP  within  the  functional 
management  and  operational  community  is  essential  to  success.  If 
Total  Quality  Management  has  already  taken  root  in  a  functional 
community,  it  can  be  used  as  the  vehicle  for  culture  change  in 
implementing  a  Business  Process  Improvement  Program.  TQM  already 
has  a  process  orientation  which  can  be  expanded  through  BPR  (via 
IDEF  modeling)  to  incorporate  the  definition  of  business  rules. 


WHAT  IS  INFORMATION  ENGINEERING  -  WHAT  ROLE  DOES  IT  PLAY? 

Information  engineering  is  defined  as: 

An  integrated  set  of  formal  techniques  for  planning, 
analysis,  design  and  construction  of  information  systems 
from  an  enterprise-wide  business  perspective. 

The  following  management  concepts  are  fundamental  to  information 
engineering: 

Functional  requirements  are  separated  from  technical 
requirements.  Process  modeling  and  data  modeling  are 
independent  of  technology  infrastructure. 
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Logical  design  is  separated  from  physical  design 

The  analysis  phase  (logical  design)  precedes  the  design 
phase  (physical  design)  so  that  the  business  rules  and 
functional  requirements  are  defined  first  -  without 
reference  to  an  IT  solution. 

The  functional  user  develops  and  models  the  business 
methods  -  including  the  business  rules.  Although  the 
programmer/ analyst  may  assist  this  process,  the 
ultimate  definition  of  the  system  requirement  takes  an 
all  new  form  and  its  accuracy  becomes  the  responsibility 
of  the  functional  proponent.  This  is  a  fundamental 
concept  of  CIM. 

Top  management  commitment  drives  the  requirements 

process.  All  levels  are  stakeholders  in  the  process. 

Information  Systems  are  built /acquired  in  accordance  with 
an  enterprise-wide  architecture. 


Figure  3  is  a  high  level  view  or  "Topology  of  IE".  It  starts 
with  a  linkage  to  the  corporate  strategic  vision.  This  is 
accomplished  through  an  Enterprise  Model  using  process  and  data 
entities  to  define  the  cross-functional  relationships.  As  a 
result  of  this  strategic  analysis,  corporate  decisions  are  made 
to  implement  a  Business  Process  Improvement  Program  within  a 
functional  area(s).  Figure  3  also  depicts  the  principal  phases 
of  the  IE  methodology:  Planning,  Analysis,  Design,  and 
Construction.  Two  of  the  principal  products  of  the  BPIP  are 
Process  (Activity)  and  Data  (Business  Rule)  models.  Once  the 
business  case  decision  is  made  (see  Figure  3),  these  models  can 
be  imported  into  the  logical  design  (Analysis  iPhase)  for  an 
information  system.  In  fact,  the  logical  design  phase  of  IE  is 
based  upon  "business  analysis",  NOT  systems  analysis.  Therefore, 
the  modeling  by-products  of  BPR  are  ideally  suited  to  provide  a 
definition  of  customer  requirements  for  the  IE  scenario.  (Of 
course,  this  assumes  that  the  business  case  produced  in  the  BPIP 
has  adopted  automation  as  the  best  business  practice  for 
leveraging  process  improvements.) 

Because  IE  data  models  and  IDEF-based  data  (business  rule)  models 
have  a  very  similar  Entity-Relationship  structure,  the  business 
rule  models  produced  from  BPR  can  be  imported  into  the  Analysis 
phase  of  IE  through  the  repository  of  an  Integrated  CASE  (ICASE) 
tool.  However,  the  IDEF-based  process  (activity)  models  and  IE 
process  models  are  structurally  quite  different.  Therefore,  the 
functional  customer  will  need  to  assist  in  the  integration  these 
models  in  the  IE  Analysis  phase. 

In  the  Design  Phase,  the  logical  system  design  from  the  Analysis 
Phase  (along  with  continued  functional  customer  input)  is  used  as 
the  functional  requirement  for  the  physical  design.  That  is  why 
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IE  TOPOLOGY  WITH  BUSINESS  PROCESS  REDESIGN 

Figure  3 


Construction  LCOD^E_GENE  RATION 


the  logical  design  is  usually  completed  before  the  physical 
design  (Design  phase)  is  begun.  Process  and  data  models 
(business  analysis)  that  were  captured  in  an  ICASE  tool  in  the 
previous  phase  continue  to  support  the  systems  analysis  in  this 
phase.  Data  base  design  and  design  level  documentation  are 
produced  from  symbolic  ICASE  products  understandable  to  the 
functional  customer  (not  machine  code) . 

The  Construction  phase  produces  computer  generated  source  code 
and  translation  to  object  code.  Even  though  today's  code 
generators  produce  essentially  error  free  code,  we  are  not 
relieved  of  the  testing  burden.  In  short,  the  testing  function 
ensures  that  the  design  functionality  captured  in  the  logical  and 
physical  design  actually  results  in  the  operational  functionality 
required.  The  management  imperative  is  that  both  testing  and 
follow-on  maintenance  (including  upgrades)  are  accomplished 
through  the  symbolic  reference  models  in  the  ICASE  tool. 

The  significance  of  the  above  discussion  is  that  the  IE  method 
has  enabled  a  new  concept  for  both  development  and  maintenance  of 
automated  information  systems.  Consequently,  a  new  management 
paradigm  for  the  application  of  CIM  concepts  for  Business  Process 
Improvement  has  arisen  which  has  implications  across  the  DoD. 


What  are  the  critical  elements  of  Information  Engineering? 


.  Enterprise  Strategic  Planning.  In  order  to  develop 
enterprise-wide  systems  that  enhance  productivity  and  show 
return  on  investment,  IE  roust  start  with  strategic  planning. 
It  takes  an  efnterprise-wide  approach  to  identifying 
requirements  for  information  systems,  based  on  business 
decisions  related  to  return  on  investment  and  productivity 
improvement .  One  of  the  cornerstones  of  the  CIM  Model  is 
the  development  of  business  measures  of  perfoirmance  on  which 
to  base  those  business  decisions.  Enterprise  strategic 
planning  usually  results  in  a  functional  area  analysis. 

This  is  where  business  process  improvement  enters  the 
picture. 

.  Business  Case.  Strategic  systems  use  information 
technology  to  change  the  way  the  enterprise  functions  are 
performed.  Focus  is  on  functionally  effective  systems  that 
meet  enterprise-wide  goals  using  shared  data.  Defining  and 
modeling  the  business  rules  is  the  key  IE  concept.  "No 
system  is  an  island."  First  use  activity  models  (IDEF)  to 
build  a  conceptual  framework  for  the  business  case.  Then 
use  IE  to  integrate  across  functional  and  organizational 
boundaries. 
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.  Top  Executive  Commitment.  Mandatory  for  success  of  CIM 
and  IE.  Key  concept  is  to  not  only  get  corporate  management 
involved  but  make  them  a  stakeholder  in  the  systems  by 
linking  systems  objectives  to  corporate  objectives. 

.  Integrated  Systems.  Driven  by  enterprise~wide  vision  and 
goals  and  integrated  across  functional  boundaries  through 
common  data  elements  and  data  management  policies.  Goal 
oriented  systems  and  processes  force  teaming  between  the 
systems  and  functional  people  to  achieve  corporate  planning 
and  design  objectives. 

.  Rapid  Application  Development  (RAD) .  Six  months  is  the 
often  refered  to  as  the  maximum  lead  time  today's  corporate 
and  functional  management  is  willing  to  wait  for  a  product. 
Therefore,  systems  development  and  functional  people  must  be 
highly  productive  and  make  use  of  rapid  development 
techniques,  facilitated  decision  making  teams,  and  automated 
tools  to  shorten  project  lead  times.  RAD  teams,  backed  up 
by  ICASE  tools  and  structured  design  methods  allow  business 
rules  to  be  modeled  in  a  design  level  language. 

.  Logical  Design  Before  Physical  Design.  This  principle 
demands  that  the  system  developers  CANNOT  build  a  "technical 
solution"  before  the  business  problem  is  defined  by 
management  and  the  functional  people.  Therefore,  the  system 
design  becomes  totally  dependent  upon  modeling  the  business 
methods  (logical  model)  before  producing  a  technical  design 
(physical  model) .  This  assumes  heavy  involvement  from  a 
Data  Administrator  and  the  functional  user  to  model  the 
relationships  between  corporate  entities  (data  model)  at  the 
(  same  time  the  processes  are  modeled  by  the  functional  user 
and  the  systems  analyst  (process  model) . 

.  CASE  Tool  Support.  IE  cannot  be  performed  effectively 
without  Computer  Aided  System  Engineering  (CASE)  tools  -  but 
CASE  tools  are  not  a  "silver  bullet".  Both  functional  and 
systems  personnel  use  CASE  tools  to  perform  their  tasks  in 
executing  the  IE  methodology.  Integrated  CASE  (ICASE) 
tools  provide  a  complete,  end-to-end,  knowledge-based 
support  environment  for  IE.  The  key  concept  is  to  develop 
the  apply  ICASE  tools  in  concert  with  an  IE  methodology  that 
fits  the  corporate  culture. 

.  Knowledge  Based.  IE  is  based  upon  an  encyclopedia  (or 
repository)  concept.  CASE  toals  center  around  a  data 
encyclopedia.  The  encyclopedia  is  the  central  collection 
facility  for  the  applications,  the  business  rules  and  the 
data  and  process  models  (along  with  many  other  artifacts) . 

It  is  the  central  coordination  facility  for  integrated 
design  and  development  using  modeling  techniques  (either 
IDEF  or  ICASE) . 
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.  Data  Sharing.  This  is  a  fundamental  precept  of  IE  and  is 
also  an  integral  part  of  the  CIM  management  strategy  using 
IDEF.  Data  sharing  starts  with  data  management  policy  and 
is  implemented  through  as  data  standards  program.  The  DoD 
now  has  a  Center  for  Data  Administration  responsible  for 
collecting  standard  data  elements  and  definitions  from  all 
services  and  agencies. 


HOW  DOES  THE  CIM  STRATEGY  FOR  BUSINESS  PROCESS  IMPROVEMENT  IMPACT 
NON-BUSINESS  SYSTEMS? 


CIM  is  an  information  oriented  management  strategy  that  has 
introduced  a  new  management  and  information  systems  development 
paradigm  for  DoD  business  systems.  The  foundation  concept  for 
such  a  strategy  is  precept  that  the  data  component  of  information 
tends  to  remain  relatively  constant  even  if  the  mission  and 
operational  component  continues  to  evolve.  Such  a  management 
strategy  is  highly  relevant  to  both  the  management  of  business 
functions  and  to  the  command  of  operational  missions.  In  modern 
warfare,  all  systems  tend  to  become  information  systems.  As 
noted  by  Mackay  (2) : 


"The  whole  endeavor  depends  on  the  management  of  information. 
Information  is  the  crux,  heart  and  linchpin  of  militarily 
useful  force.  Therefore,  by  depriving  the  enemy  of  the 
ability  to  manage  and  exploit  information,  one  destroys  his 
ability  to  generate  as  well  as  coordinate  military  force." 

The  CIM  management  strategy  is,  above  all  else,  a  strategy  for 
managing  and  controlling  information.  Figure  4  shows  a  notional 
representation  of  the  spectrum  of  applications  within  which 
information  systems  and  information  management  are  operative  in 
the  DoD.  Even  though  there  may  be  some  abstract  resemblance  of 
mission  systems  to  sales  and  competition,  the  private  sector 
really  does  not  have  an  analogue  to  the  C2  and  mission/weapons 
system  environments.  There  are  three  operational  environments  in 
Figure  4:  Business,  Command  and  Control,  and  Weapons  or  Mission. 
Within  each  of  these  environments  information  systems  play  a 
strategic  role.  The  overlaps  between  these  environments  reflect 
the  commonality  of  application  characteristics  between 
operational  systems  (e.g.  many  C2  systems  have  large  data  base 
and  transaction  processing  design  requirements  much  like  business 
systems) .  The  implication  of  these  overlaps  to  the  development 
and  integration  of  information  systems  is  not  yet  fully 
understood.  However,  the  CIM  Integration  Architecture  discussed 
below  provides  a  model  for  resolving  the  integration  issues 
across  these  overlaps. 
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THE  INFORMATION  SYSTEM  APPLICATION  SPECTRUM 

Figure  4 


c 

.2 


The  continuum  of  information  systems  applications  in  Figure  4  is 
a  model  of  the  logical  leap  of  faith  required  for  military 
commanders  to  adopt  the  CIM  doctrinal  management  principles. 

The  management  principles  that  were  originally  applied  in  the  ELG 
Plan  to  the  business  systems  ("TAIL")  are  now  becoming  the 
guiding  principles  for  command  and  control  systems  as  well  -  with 
a  possible  extension  to  some  weapons  and  mission  based  systems 
(the  "Tooth").  It  may  be  easier  to  make  a  case  for  the 
projection  of  CIM  across  the  application  spectrum  using  logistics 
or  medical  systems;  But  what  does  payroll,  personnel,  finance  and 
contract  payment  have  to  do  with  command  and  control  of  forces  - 
much  less  military  operations? 


It  has  been  estimated  that  80  percent  of  the  cost  of  the  new  F-22 
Fighter  is  software.  A  ready  comparison  can  be  made  to  the 
makeup  of  the  WWMCCS  system  and  the  cost  of  the  Navy's  new 
Copernicus  system.  It  appears  that  the  application  of  CIM 
doctrine  to  these  environments  is  based  on  the  concept  that  there 
are  two  command  management  threads  which  run  the  gamut  of  the  DoD 
Application  Spectrum:  (1)  All  systems  are  becoming  information 
systems.  (2)  An  information  war  (which  some  have  said  Dessert 
Storm  was  the  precursor)  requires  the  fullest  possible 
interoperability  -  and  interoperability  will  come  only  through 
systems  integration. 

There  are  also  two  common  information  management  threads  that 
cross  the  continuum  in  Figure  4:  (1)  Managing  data  and  the 

process  of  its  conversion  to  information  is  the  basis  for 
managing  information  systems.  (2)  Managing  the  software 
development  and  maintenance  process  will  determine  who  wins  the 
interoperability  and  integration  battle. 


HOW  DOES  DOD  MANAGE  DATA  UNDER  CIM? 

The  imperatives  for  managing  data  and  its  conversion  to 
information  in  the  DoD  are  shown  in  Figure  5.  Note  the  role  of 
the  functional  community  in  data  base  stewardship  (data 
ownership)  and  the  concept  of  issuing  standard  data  definitions 
as  government  furnished  material  (GFM)  to  contractors  or  DoD 
agencies  who  are  building  information  systems.  Information 
management  rules  such  as  those  in  Figure  5  are  an  essential 
characteristic  of  information  engineering  based  methodologies. 
There  are  two  components  of  data  management  which  must  be 
implemented  under  CIM:  Data  Administration,  and  Data  Standards. 
Data  Administration  refers  to  assigning  resources  to  manage  the 
corporate  data  base.  As  a  minimum.  Data  standardization  refers 
to  adopting  standard  data  elements  and  attributes  through  the  DoD 
Data  Administraiton  Center  in  Falls  Church,  Va. 
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HOW  IS  IE  DIFFERENTIATED  FROM  SOFTWARE  ENGINEERING? 


.  "Software  engineering  applies  structured  techniques  to 
one  project. 

.  INFORMATION  ENGINEERING  APPLIES  STRUCTURED,  AUTOMATED 
TECHNIQUES  TO  THE  ENTERPRISE  AS  A  WHOLE. 


.  Software  engineering  is  about  building  software. 

.  INFORMATION  ENGINEERING  IS  ABOUT  THE  DATA  THAT  IS  STORED 
AND  MAINTAINED  BY  COMPUTERS  AMD  THE  INFORMATION  THAT  IS 
DISTILLED  FROM  THAT  DATA. 

.  Software  engineering  refers  to  a  set  of  disciplines  used 
to  specify,  design,  and  program  software. 

.  INFORMATION  ENGINEERING  REFERS  TO  A  SET  OF  INTERRELATED 
DISCIPLINES  USED  TO  BUILD  A  COMPUTERIZED  ENTERPRISE 
BASED  ON  INFORMATION  SYSTEMS. "(7) 


As  a  result  of  Corporate  Information  Management,  supported  by 
IE,  there  are  two  fundamental  changes  that  take  place  in  the 
corporate  culture; 

(1)  With  software  engineering,  the  programmer  analyst  is 
responsible,  by  default,  for  modeling  the  business  methods. 
WITH  IE,  THE  FUNCTIONAL  USER  SHARES  CORPORATE  RESPONSIBILITY 
FOR  MODELING  THE  BUSINESS  METHODS. 

I 

(2)  With  software  engineering,  the  information  resources 
manager  is  responsible  for  the  final  system's  efficiency  and 
effectiveness.  WITH  IE,  THE  FUNCTIONAL  USER  BEARS  JOINT 
RESPONSIBILITY  FOR  THE  NEW  SYSTEM'S  PRODUCTIVITY  ALONG  WITH 
THE  INFORMATION  RESOURCE  AND  CORPORATE  MANAGERS. 


HOW  DOES  DOD  MANAGE  SOFTWARE  DEVELOPMENT  UNDER  CIM? 

Refer  to  the  three  circles  in  the  upper  portion  of  Figure  4. 

These  represent  the  three  software  domains  which  are  essential  to 
any  automated  information  system.  (1)  The  Application  domain  is 
the  software  representation  (model)  of  the  real  world  processes 
and  provides  the  operational  functionality  required  -  be  it 
handling  payroll  transactions  or  monitoring  engine  heat  levels  on 
the  Apache  Helicopter.  The  application  domain  is  the  principal 
focus  of  most  management  activities,  whether  by  a  program  manager 
or  by  GAO  and  Congress.  However,  the  application  domain  is  not 
sufficient  by  itself  to  fully  support  the  application  system. 
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(2)  The  Support  Structure  Domain  provides  all  the  infrastructure 
support  necessary  for  both  development  and  operation  of  the 
application.  In  recent  years,  standards  have  been  developed  for 
the  Support  Domain  to  communicate  with  the  Application  and  Data 
domains.  The  standard  programming  language,  Ada,  has  been 
adopted  to  generate  application  software  using  software 
engineering  methods.  There  are  also  Integrated  Computer 
Assisted  Software  Engineering  (ICASE)  tools,  coupled  with 
information  engineering  design  and  development  methods  which 
automate  the  generation  of  computer  code.  Within  the  Support 
domain,  GOSIP,  POSIX  and  XWINDOWS,  along  with  an  entire  suite  of 
standards  (reference  model) ,  have  been  adopted  under  CIM  to 
provide  a  full  complement  of  test,  evaluation  and  operational 
support  features. 

(3)  Modern  software  engineering  procedures  maintain  the  full 
independence  of  the  Data  Domain  from  the  other  two  domains  in 
Figure  4.  In  fact,  modern  information  engineering  design  and 
development  methods  using  ICASE  tools  negate  any  direct 
communication  between  the  application  and  data  domains.  The 
support  domain  communicates  with  the  data  domain,  through  a  Data 
Base  Management  System  (DBMS)  using  the  Federal  Standard, 
Structured  Query  Language  (SQL) . 

The  domain  structure  in  Figure  4  demonstrates  one  of  the 
fundamental  principles  of  CIM:  The  separation  of  data  base  design 
from  application  systems  design.  Those  Tail  systems  shown  in  the 
Business  environment  in  Figure  4  require  only  a  loosely  coupled 
set  of  software  domains  and  communication  between  domains  is 
controlled  by  standard  support  structure  components. 


THAT'S  FINE  FOR  TAIL  SYSTEMS  BUT  WHAT  ABOUT  TOOTH  SYSTEMS? 

Looking  at  the  "Tooth”  end  of  the  spectrum  in  Figure  4,  note  that 
there  is  a  much  tighter  coupling  between  the  three  domains  cited 
earlier.  This  is  due  to  the  real-time  constrains  which  generally 
drive  the  design  consideration  for  weapons  and  mission  systems 
applications.  This  tighter  coupling  does  not  negate  the  use  of 
standards.  However,  it  does  impose  different  software  design 
considerations,  and  therefore,  different  management  paradigms. 

For  example,  it  is  not  likely  that  software  designers  for  the  ATF 
will  employ  a  database  management  system  to  process  transactions 
from  target  acquisition  radar.  The  data  domain  must  be  very 
tightly  coupled  with  the  support  and  application  domains  in  order 
to  meet  real  time  operational  requirements  at  mach  speeds. 


Ada  is  the  language  of  choice  for  these  applications  and  they 
generally  employ  object  oriented  design  methods  in  the  software 
engineering  process.  Because  these  applications  are 
characteristically  driven  by  operational  parameters  which  cannot 
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be  supported  by  the  loosely  coupled  model  for  "Tail”  systems, 
"Tooth”  systems  are  also  commonly  supported  by  manual  coding 
techniques.  These  imperatives  for  managing  systems  design  and 
development  have  become  the  drivers  for  significant  differences 
in  management  paradigms  between  Tooth  and  Tail. 


HOW  DO  DESIGN  AND  DEVELOPMENT  METHODS  DIFFER  BETWEEN  TOOTH  AND 
TAIL? 

Within  the  last  two  years  there  have  been  major  advances  in 
Integrated  CASE  (ICASE)  tools,  particularly  in  their  ability  to 
generate  error  free-code.  This  capability  provides  major 
productivity  improvements  in  the  software  development  process. 
However,  these  savings  are  totally  eclipsed  by  one  additional 
value-added  opportunity:  For  the  first  time  ever,  DoD  has  the 
chance  to  get  control  over  the  software  maintenance  burden. 
Numerous  studies  are  available  to  attest  to  the  fact  that 
maintenance  of  legacy  systems  devours  some  75%  to  85%  of  all 
personnel  resources  available  for  software  support.  The  ability 
to  m^ke  corrections  or  upgrades  to  application  software  without 
wallowing  in  patches  upon  patches  at  the  source  code  level 
represents  a  major  breakthrough.  Integrated  CASE  tools  make  it 
possible  to  gain  control  over  software  configuration  management 
by  elevating  the  initial  design  and  subsequent  development  and 
maintenance  efforts  to  a  set  of  symbolic  (process  and  data) 
models  which  are  maintained  in  the  repository  of  the  ICASE  tool. 
When  this  capability  is  coupled  with  automated  code  generation, 
scarce  and  costly  human  resources  that  are  now  shackled  to  old 
code  maintenance  are  released  for  more  productive  requirements. 
The  Director  of  Defense  Information  has  taken  a  lead  role  in  a 
program  tp  acquire  an  Integrated  CASE  tool  set  for  achieving  the 
above  outcomes. 

The  above  scenario  is  not  all  good  news.  For  many  years  there 
was  one  consistent  management  paradigm  attributed  to  the  entire 
application  spectrum  in  Figure  4: 


INTERNAL  MEMORY  IS  EXPENSIVE;  EXTERNAL  MEMORY  IS  EXPENSIVE; 
THEREFORE,  MANDATE  A  PROGRAMMING  LANGUAGE  (Ada)  WHICH  WILL 
GIVE  THE  MOST  EFFICIENT  OPERATIONAL  SYSTEM  AND  WILL  SUPPORT 
SOFTWARE  ENGINEERING  METHODS. 


As  a  result  of  the  above  paradigm,  Ada  has  been  mandated  (and 
legislated)  for  all  DoD  systems  development.  This  management 
paradigm  is  still  highly  relevant  to  a  large  segment  of  the 
application  spectrum  in  Figure  4.  However,  with  the  advent  of 
ICASE  tools  and  automated  code  generation  a  new  management 
paradigm  has  emerged  for  development  and  maintenance  of  Tail 
systems: 


12 


THE  ONLY  RESOURCE  WHOSE  PRICE/ PERFORMANCE  RATIO  IS 
CONSISTENTLY  INCREASING  IS  HARDWARE  -  THEREFORE,  (IF 
POSSIBLE)  NEVER  DO  MANUAL  COOING. 


Those  who  practice  IRM  in  the  DoD  are  beginning  to  realize  that 
there  is  a  fundamental  paradigm  shift  in  management  practice 
somewhere  along  the  application  spectrum  between  Tooth  and  Tail. 
It  is  presumed  here  that  this  shift  occurs  somewhere  in  the 
command  and  control  environment.  Knowing  and  applying  the 
appropriate  management  paradigm  (information  engineering  vs. 
software  engineering)  is  critically  important  to  the  development 
of  integrated  information  systems. 

It  should  be  stated  at  the  outset  that  a  healthy  relationship  can 
and  should  exist  between  the  management  strategies  for 
Information  Engineering  (Tail)  and  Software  Engineering  (Tooth) 
systems.  One  approach  is  not  more  technically  nor  managerially 
correct  than  the  other.  When  applied  correctly  and  in  the 
appropriate  application  environment,  each  methodology  produces 
quality  results.  However,  this  is  not  an  "I'm  OK  -  You're  OK" 
situation  either.  There  is  a  battle  going  on  between  the  two 
which  will  not  be  resolved  by  the  DoD.  Each  is  learning  from  and 
borrowing  techniques  from  the  other.  Software  Engineering  is 
using  CASE  tools  and  process  and  data  modeling  methods  borrowed 
from  IE.  Similarly,  IE  is  borrowing  object  oriented  methods  from 
Software  Engineering.  This  give-and-take  is  expected  to  go  on  as 
long  as  both  of  the  foregoing  management  paradigms  continue  to  be 
prevalent.  CIM  is  the  only  management  strategy  which 
accommodates  both  of  these  paradigms  and  provides  both  the 
doctrine  and  the  tools  to  make  them  work. 


HOW  DOES  CIM  SUPPORT  THE  PARADIGM  SHIFT  BETWEEN  TOOTH  AND  TAIL? 

The  CIM  initiative  has  been  extremely  perceptive  in  recognizing 
the  management  paradigm  shift  between  Tooth  and  Tail  and  has 
adopted  doctrinal  precepts  which  accommodate  both  approaches. 
Appendix  B  contains  the  CIM  Information  Management  Doctrine  for 
DoD.  The  CIM  Directions  which  give  overall  orientation  to  the 
doctrinal  concepts  are  the  following: 


CIM  systems  shall  evolve  from  function-centric,  theater¬ 
centric  and  service-centric  orientations  towards 
decentralized  systems  that  support  Joint  Task  Forces. 

U.S.  Military  forces  must  possess  instantly  interoperable 
information  systems  to  be  able  to  "fight  on  arrival". 


13 


To  gain  economy  and  accelerate  standardization,  increased 
emphasis  shall  be  placed  on  support  from  centrally 
managed,  shared  resources. 


Management  Concepts  that  support  those  CIM  Directions  are  the 
following; 

.  Derive  information  management  strategies  directly  from 
war  plans. 

.  Establish  technical  systems  integration  capabilities  as  a 
core  Defense  capability. 

.  Replace  current  over-emphasis  on  technology  acquisition 
with  functional  improvements  and  cost  reduction. 

APPLY  BUSINESS  PROCESS  REDESIGN  AS  A  CONTINUOUS, 
INCREMENTAL  AND  EVOLUTIONARY  PRODUCTIVITY- ENHANCEMENT 
PROCESS . 


HOW  CAN  THE  CIM  MANAGEMENT  DOCTRINE  BE  PROJECTED  FROM  TOOTH  TO 
TAIL? 

The  CIM  doctrine  is  guided  by  an  Integration  Architecture,  see 
Figure  6,  which  defines  the  both  the  levels  of  integration  and 
the  interfaces  required  to  project  the  CIM  integration  doctrine 
from  tooth  to  tail.  The  architecture  in  Figure  6  is  founded  on  a 
solid  support  structure  of  Policy,  Doctrine,  Standards,  Reference 
Models,  Data  Management  and  Tools  which  are  given  focus  and 
direction  by  the  CIM  doctrine  in  Appendix  B.  This  "Enterprise 
Layer"  provides  the  management  and  technical  infrastructure  on 
which  to  build  integrated  systems  across  the  Application  Spectrum 
in  Figure  4.  Included  in  this  infrastructure  is  the  policy, 
process,  methods  and  tools  to  support  Business  Process 
Improvement  and  IE-based  systems  design  and  development. 

The  second  layer  of  the  CIM  Integration  Architecture  is  the 
Mission  Layer.  This  layer  bears  a  strong  resemblance  to  the 
Information  System  Application  Spectrum  in  Figure  4.  Application 
systems  are  built  upon  the  infrastructure  of  the  Enterprise  layer 
to  support  the  requirements  of  the  mission  areas  of  the  Mission 
Layer.  Mission  requirements  at  this  level  are  based  on  the 
following  CIM  principles: 


Derive  information  management  strategies  directly  from 
war  plans. 
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CIM  INTEGRATION  ARCHITECTURE 

Figure  6 


Establish  technical  integration  capabilities  as  a  core 
Defense  capability. 

Design  Systems  according  to  DoD  reference  models. 

Follow  industry  and  FIPS  standards  -  MIL  standards  only 
if  necessary. 

Reserve  for  DoD  the  capability  to  fully  support  its 
Enterprise,  Domain  and  Functional  reguirements  and 
integration  needs. 


The  first  level  of  integration  occurs  between  the  Enterprise 
Layer  and  The  Mission  Layer  -  and  between  mission  areas  in  the 
Mission  Layer.  This  is  where  technology  can  be  either  an 
integrating  force  or  a  force  divider.  Therefore,  the  emphasis  is 
on  building  systems  with  standards  and  managing  data  elements  as 
the  fundamental  piece-parts  of  integration. 

The  Functional  Layer  contains  the  business  processes  that  drive 
the  information  systems  at  both  the  Mission  Layer  and  the 
Application  Layer.  This  is  where  Business  Process  Improvement 
and  BPR  become  the  linchpin  to  integration.  Capturing  the 
business/operational  rules  in  models  makes  it  possible  to 
actually  integrate  vertically  and  horizontally  across  the  CIM 
Integration  Architecture. 

As  demonstrated  by  Figure  7,  The  CIM  Architecture  can  be  mapped 
to  the  IE  Topology.  The  DoD  Enterprise  Layer  is  the  driver  for 
corporate  vision  and  Enterprise  Modeling  within  the  services. 

The  Mission  and  Functional  Layers  implement  the  CIM  doctrine  for 
Business  Process  Improvement  and  for  building  information  systems 
on  a  business  case  basis.  In  the  Application  Layer,  IE  methods 
are  used  to  build  maintainable  systems  from  the  requirements 
specified  by  the  business  rule  models  in  the  Functional  Layer. 
Business  processes.  Command  and  Control,  and  Intelligence 
processes  are  cross-functional  disciplines  that  bridge 
organizational  boundaries.  By  defining  the  decision  rules  that 
implement  those  processes  we  can  first  understand  them  (and 
equally  important  control  them)  and  use  them  as  the  integrating 
component  between  the  Mission  Layer  and  the  Application  layer. 

At  the  Application  layer  information  engineering  (or  software 
engineering)  methods  are  used  to  convert  the  models  of  business 
processes  and  business  rules  into  logical  and  physical  models. 
These  models  become  the  requirements  statements  for  the 
development  of  information  systems  that  will  support  cross¬ 
functional  applications. 
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MAPPING  THE  IE  TOPOLOGY  TO  THE  CIM  ARCHITECTURE 

Figure  7 


INFORMATION 

SYSTEM 
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This  is  the  cmix  of  CIM.  By  getting  control  of  the 
functionality  through  capturing  the  business  rules,  we  can 
finally  get  control  of  the  run-away  information  systems  that 
have  grown  up  helter  skelter  to  support  the  "perceived 
functionality".  The  logical  extension  of  this  concept 
beyond  the  business  environment  is  to  capture  the  "decision 
rules"  as  they  relate  to  command  and  control  or  intelligence 
processes.  This  may  someday  result  in  a  methodology  for 
"decision  process  improvement."  cross  functional 
interoperability  can  then  be  enabled  through  a  common 
management  paradigm  for  information  integration. 


JCS  Pub  2  (4)  defines  the  "Principle  of  Interoperability": 

"Unified  action  demands  maximum  interoperability.  The 
forces,  units,  and  systems  of  all  Services  must  operate 
together  effectively.  This  effectiveness  is  achieved  in 
part  through  interoperability,  which  includes  collective 
effort  to  develop  joint  doctrine  and  joint  tactics, 
techniques,  and  procedures;  the  development  of  joint  plans 
and  the  conduct  of  joint  training;  and  a  material 
development  and  fielding  process  which  is  fully  compatible 
with  and  complementary  to  systems  of  all  Services." 


The  CIM  management  paradigm,  in  context  with  the  Integration 
Architecture,  holds  the  greatest  promise  of  achieving  this 
principle. 


CAM  CIM-BASED  INTEROPERABILITy  AMD  IMTE6RATI0M  BECOME  A  UMIFYIMG 
COMCEPT? 


"This  is  not  to  suggest  that  the  action-reaction  cycle  of 
measure  and  counter-measure  is  likely  to  be  repealed  -  in 
fact  it  is  more  intense  than  ever.  What  is  suggested, 
however,  is  that  the  ultimate  winner  in  this  contest  will 
not  necessarily  be  the  side  with  the  latest  piece  of 
electronic  gadgetry.  Rather,  the  armed  forces  that  gather 
and  exploit  the  most  critical  information  are  likely  to  have 
the  decisive  advantage." 

In  the  above  citation  Allard  (3)  is  referring  to  the  increasing 
awareness  of  the  "Information  War"  concept.  His  book  makes  some 
interesting  observations  regarding  the  potential  future  role  of 
the  Joint  Chiefs  of  Staff  in  this  area.  He  also  chronicles  many 
of  the  negative  impacts  of  a  lack  of  integration  on  the 
battlefield  in  the  case  of  the  Joint  Tactical  Integrated  Data 
System  (JTIDS) .  The  CIM-directed  approach  to  Business  Process 
Improvement  -  when  projected  from  tooth  to  tail  -  is  a  critical 
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element  of  a  new  management  context  for  exploiting  critical 
information.  Allard  also  perceives  the  information  war  of  the 
future  to  have  potential  for  changing  the  way  we  establish 
operational  objectives: 


"Although  the  promise  of  modern  command  and  control  stops 
well  short  of  completely  dissipating  the  fog  of  war,  it  has 
the  potential  to  turn  night  into  day,  achieve  spans  of 
control  that  can  be  measured  in  global  terms,  and  to  mass 
collective  combat  power  without  massing  forces." 


WILL  THE  FUNCTIONAL  COMMUNITY  SUPPORT  THE  CONCEPT? 


"Distributed  information  sharing  can  be  utterly  subversive 
of  the  notion  of  military  hierarchy,  which  for  all  practical 
purposes  considers. .. information  lines  to  be  identical ...  it 
may  well  be  that  command  and  information  lines  will 
diverge. . . (the)  ability  to  move  information  so  quickly  will 
extend  the  commander's  span  of  control  in  ways  that 
revolutionize  military  operations  itself." 


The  above  citation  (3)  illustrates  the  contentious  nature  of 
information  management  and  information  itself  as  a  component  of 
Defense  strategy.  Although  there  may  be  some  structural  limits 
on  the  application  of  the  CIM  integration  paradigm  across  the 
application  spectrum  in  Figure  4,  there  seems  to  be  a  universal 
understanding  of  the  need  for  interoperability  -  and  hopefully 
the  information  integration  paradigm  which  can  be  the  enabler  for 
interoperability.  The  IRM  College  may  be  in  a  position  to  help 
shape  the  future  of  this  paradigm  and  give  it  meaning  as  a 
component  of  future  DoD  Strategy - 

"The  future  war  will  be  an  information  war.  You  actually 
win  before  you  start  shooting.  It's  an  intelligence  war,  a 
C3I  war,  ....  a  command  and  control  war.  He  have  to  start 
rethinking  the  IRM  mission  as  a  war  prevention  . . .  and 
ultimately,  war  winning  engine  -  not  as  a  COBOL  payroll 
system  or  a  data  base  system  -  that's  in  the  background. 

The  idea  of  fielding  information  technology  the  way  we 
fielded  muskets  ...  is  over." 

Address  by  Mr.  Paul  Strassmann  to  the 
IRM  College,  6  June  1991. 
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Initial  steps  should  focus  on  process  simplification  or  process  elimination. 
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Appendix  B 


The  Role  of  Funaional  Integration  in  Corporate  Information  Management 
REVIEW  DRAFT  FOR  STAFF  COMMENTS.  5  January  1992 


DoD  In/oftmtion  MaMsement  Doctrine  »  Atonaf emenf 


•  Derive  information  ounagement  stntepes  director  from 
warfrfans 

•  EstaUish  tedmicaJ  systems  integration  capabilities  as  a  core 
Defense  capability 

•  Replace  current  over-em^usis  on  technology  acq^tion  by 
planning  for  total  functional  life<yde  costs 

•  Apply  business  re^gineering  as  a  continuoiis.  Incremental 
and  evolutionary  productivity-enhancement  process 

the  functional  customer  for  information  tedmology 
activity-based  costing 

•  Benchmaric  transaction  co^  ag^unst  oommerdal  services 


DoD  Information  Managemenf  Doctrine  -  Resources 

•  Evaluate  functioiul  costs,  not  information  technology 

:  •  Reserve  for  OoD  the  capability  to  fully  support  its 
Enterprise,  Domain  and  Functional  requirements  and 
integration  needs 

:  •  Rely  on  commercial  sources  for  delivery  information  aD 
technologies  except  for  those  expressly  reserved 

^  •  Justify  applications  on  thebasb  of  discounted  cash  flow 
analysis 

;  •  Justify  shared  computing  and  telecommunications  resources 
on  the  basis  of  revenue  from  transactioitt 


The  Role  of  Functional  Integration  in  Corporate  Information  Managemertf 

REVIEW  DRAFT  FOR  STAFF  COMMENTS,  5  January  1992 


DoD  Informithn  Kiani^etnent  Doctrine  -  Security 

•  Expect  that  infonnation  Querns  are  choice  war  targets 

•  Validate  each  systems  design  for  war-scenario  survivability 

•  Evaluate  stuvivability  in  terms  of  msurartce  economics 
:  •  Achieve  survival^ty  primarily  through  redundaiKy 

:  •  Support  critical  data  bases  From  low-risk  sites 

•  Escalate  the  enforcement  of  iitformation  security 

•  Subject  network  to  hostile  tests  to  identify  exposiues 

•  Control  access  to  networii  entry  points,  espedafly  for 
software  management  and  maintenance 

•  Design  security  into  hardware  configurations 

•  Maintain  central  monitoring  over  mission<ritica]  teminab 

. . ~  ‘ 


OoD  lnforw3tion  Mamgement  Doctrine  -  Data 

•  Mandate  singlepoint  entry  of  data 

•  Require  DoD  certification  of  all  data  definitions 

•  Set  immutable  enterprise-wide  data  definitioitt 

•  Assure  single  source  data  origination  stewardship 

•  Use  data  base  stewardship  to  set  functional  boundanes 

•  Issue  data  definitions  as  Government  Furnished  Material 

•  Dictate  the  maintenance  of  data  models  for  all  applications 

•  Centralize  database  backup  and  archival  functiorui 

•  Store  and  distribute  images  in  standard  compressed  format 

•  Pursue  electronic  data  interchange  agreements  with  other 
agencies,  suppliers  and  contractors 


The  Role  of  Functional  Integration  in  Corporate  Information  Management 

REVIEW  DRAFT  FOR  STAFF  COMMENTS,  5  JafHjaiy  1992 


•  Use  o£f*the^hel/  hardware  and  software 

•  Lengthen  technology  life  by  continuous  upgrading 

•  ^stribute  hardware  and  software  from  re-use  "warehouses* 

•  Require  single  workstation  for  individual  infomution  needs 

•  Establish  standardization  of  display  interface  style 

•  Commit  to  vendor-independent  inter-operable  ^sterns 

•  Pursue  a  distributed  dient/server  architecture 

•  Provide  scalable  computing  capacity  using  microprocessors 


TtPHiJiEiiimnsnMitR 


•  Design  systems  according  to  the  DoD  Reference  Models 

•  FoOow  industry  standards,  FIPS  standards  if  industry 
standards  not  available  and  MIL  standards  only  if  necessary 

•  Define,  store  and  distribute  software  objects 

•  Adopt  a  software  development  toolset 

•  Define  a  process  and  data  mcxieling 

•  Specify  a  method  for  economic  analysis  of  systems 


The  Rote  of  Functional  Integration  in  Corporate  Information  Management 

REVieW  ORAH  fOR  STAFF  COMMENTS.  5  January  1992 


DoD  Information  AUmeement  Doctrine  •  Design 

•  Pursue  evolutiofury  ar>d  incremental  systems  deployment 

•  Design  by  prototype  within  a  generally  defined  strategy 

•  Train  as  you  fight  and  design  (prototype)  as  you  train 

•  Give  customers  capacity  for  complex  inquiries 

•  Trarufer  report-generation  responnbilities  to  customers 

•  Allow  for  rapid  re-configuration  of  design  functions 

•  Have  business  process  redesign  precede  systems  design 

•  Cortstruct  variety  from  software  elements  and  not  hardware 

•  Always  separate  software  into  data  management 
applications,  reporting  and  output  standard  components 


DoD  Information  M^nigemenr  Doctrine  -  Network 


•  Treat  commuiucation  networks  designs  as  mseparable  from 
computer  systems 

•  View  the  computer  network  as  an  extended  workstation 

•  Recognize  the  inherent  vulnerability  of  all  networks  in  w^ 
and  therefore  place  computing  capacity  at  point  of  use  ^ 

•  Integrate  data,  voice,  graphics  and  video  into  a  shared 
network 

•  Establish  central  management  of  all  communication 
networks 

•  Provide,  as  a  central  service,  value-added  communications 
functions  such  as  directory,  security,  information 
interchange  and  software  distribution  services 


